PCT ORGANISATION MONDIALE DE LA PROPREETE INTELLECTUELLE 

Bureau international 




DEMANDS INTERNATIONALE PUBLIEE EN VERTU DU TRAITE DE COOPERATION EN MATERE DE BREVETS (PCT) 



(51) Classification Internationale des brevets 6 : 
G07F7/10 



Al 



(11) Numero de pubUcatioa interna tionak: WO 96ZJ2701 
(43) Date de publication Internationale: 17 octobre 1996 (17.10.96) 



(21) Numero de la demande interna tionale: PCT/FR96V00500 

(22) Date de depot International: 3 avril 1996 (03.04.96) 



(30) Donnees relatives a la prioriti: 

95/04533 14 avril 1995 (14.04.95) FR 



(71) Deposant: G C TECH [FR/FRJ; 16, place Venddme, F-75001 

Paris (FR). 

(72) Enventeurs: PAYS, Paul-Andrt; 34, rue Juliette- Adam, F- 
91190 Gif-sur-Yvette (FR). BEN DAHAN, Gerard; 5,* rue 
d'Alsace, F-75010 Paris (FR). 

(74) Mandatalres: JOLY, Jean-Jacques etc.; Cabinet Beau^ie- 
Lomeme, 158, rue de PUniversitf, F-75007 Paris (FR). 



(81) Etats desfenes: AU, BR, CA. CN, HU, JP, KR, MX, RU, SG 
brevet europecn (AT, BE, CH, DE, DK, ES, FI, FR GB* 
GR, IE, IT, LU. MC, NL, PT, SE). 



Publiee 



Avec rapport de recherche internationale. 
Avant V expiration du dilai privu pour la modification des 
revendications. sera repMiie si de telles modifications sont 
regues. 



(54) Title: ELECTRONIC PAYMENT METHOD FOR PURCHASE-RELATED TRANSACTIONS OVER A COMPUTER NETWORK 
^ ESS «S^™ D ™ DES RACOONS UEES A L'ACHAT 
(57) Abstract 

A method using an open communication 
network (10) to which retailer server stations 
(20) and customer stations (30) are connected. 
According to the method, a retailer server station 
generates a payment slip for tbe planned purchase 
transaction between the retailer and a customer, 
which slip comprises data on the retailer, the 
customer, the purchased item or service and 
the price; the payment slip is transmitted over 
die network to a payment server station (40); 
the payment server automatically checks whether 
the payment of said price is authorised for the 
customer in question, by querying the client's 
personal account set up in the payment server 
for paying small amounts, or, in tbe case of 
larger amounts, by making a query over a banking 
network (50) separate from the computer network 

(10); if the payment is authorised, the payment server generates a cash voucher comprising at least 
and the cash voucher is transmitted to the retailer to enable the purchase to go ahead. 




*0 

some of the data on the payment slip; 



(57) Abrtgi 



Le precede utilise un reseau de communication ouvcrt (10) sur kquel sont connects des posies serveurs de raarchands (20) et des 
oostes clients (30) et comprend: 1'elaboration par un poste serveur de maichand d'un ticket de paiement, concemant un achat envisage entre 
Kchand et un client, et comportant des informations relatives au marchand, au client, a I'objet de Pachat et & son pnx; la transmiss.on 
du ticket de paiement via le reseau a un poste serveur de paiement (40); la verification automatique par le serveur de paiement si le paiement 
du prix est autorise pour le client concerns, soil par interrogation d'un compte client piopre au client, tenu par le serveur de paiement, et 
destint au paiement des pedis montants. soil par interrogation sur un reseau bancaire (50) ind6pendant du rfs«tu informaUque (10), pour 
les paiemems de montants plus fleves; si la verification est positive. 1'elaboration par le serveur de paiement d un bon de caisse component 
au moins une partie des informations du ticket de paiement; et la transmission du bon de ca>sse au serveur de marchand afin d autonser la 



realisation de l'achat. 
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Pn>c£d£ de paiemcnt eJectronique permettant d'efTectuer des transactions liees 
a l'achat de biens sur un reseau informs toque 

La presente invention conccrne un precede de paiemcnt electronique 
permettant d'effectuer des transactions liees a l'achat de biens offerts par des 
marchands au moyen de services t&ematiques via un reseau de telecommunication 
infonnatique ouvert sur lequel sont connectes des postes serveurs de marchands ct 
des postes clients. 

Par reseau informatique ouvert, on entend ici un reseau sur lequel des 
particuliers ou des enrreprises peuvent libreraent sc connecter a la condition de 
disposer d'une adressc, par excmple le reseau "Internet". Les biens concern 6s sont 
des produits ou des services, dont la foumiture est realisee hors du reseau apres la 
conclusion de la transaction, ou des biens immateriels, tcls que des informations, 
dont la foumiture peut etre realisee via le reseau infonnatique. 

Divers precedes de paiement electronique ont ete proposes, certains 
etant deja opcrationnels. 

Plusieurs precedes sont fondes sur une nouvelle representation de la 
monnaie. II s'agit d'une representation electronique, quelquefois denoramee "jeton" 
qui peut etre purement logiciclle ou partiellement matericllc, par excmple avee une 
carte a puce. Ces precedes impliquent la circulation de monnaie sur 1c reseau 
infonnatique, ce qui pose des problemes difficiles de security vis-a-vis de la 
creation de fausse monnaie. 

D'autrcs precedes connus de paiement electronique impliquent une 
relation directe avee une banque ou un reseau bancaire. Typiquement, de tels 
25 precedes sont employes dans les rescaux dc carte de credit comme, par exemple, 
des precedes bien connus utilisant des terminaux points de vente relics a un circuit 
carte bancaire ainsi que des precedes utilisant des cheques electroniques avee une 
signature electronique pour I'authentification de 1'acheteur. Cest une forme dc 
lettre d'engagement crnise par un acheteur, remise au vendeur et acceptee et 
30 reconnue par une banque. 

Les precedes qui impliquent a un moment ou un autre de la transaction 
une relation avee le systeme bancaire traditionncl ct la mise en oeuvre d'une 
transaction dans ce systeme presentent des inconv^nients. Ainsi, les transactions 
dans 1c systeme bancaire ont un cout reel qui devient prohibitif loreque le montant 
35 dc l'achat est tres faible, par exemple un montant assocte a la consultation d'une 
base de donnces. Or, les reseaux informatiques sont bien adaptes a la vente de 
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bicns de faible valeur, principalernent des bieos ^information, puisque la livxaison 
du bien pcut se faire par le r6seau lui-meme. En outre, l'acces a un rcscau bancairc 
ou un rcscau dc carte bancairc doit ctre hautcmcnt protege, ce qui exclut 
pratiquemcnt la possibility d'un acccs a travcrs un reseau informatique ouvert, tel 

5 que le rcscau "Internet" sur lequel des acheteurs potcntiels peuvent sc connecter. 

L'invcntion a pour but de fournir un proc£de penncttant d'6vitcr les 
inconv6nients des proc6des connus, en particulier un proc6d6 penncttant, sans 
circulation de monnaie 61ectroniquc, de r£aliser de fa$on simple ct fiable des 
transactions liecs a Fachat de biens sur un rescau informatique, ct ce aussi bien 

10 pour des biens de prix eleve necessitant unc autorisation par le systeme bancaire 
traditionnel, que pour des biens dc faible ou tres faible prix. 

Ce but est atteint grace a un procede du type defini en tete de la 
presente description et comport ant, conformement a l'invention, les 6tapes de : 

- elaboration par un postc serveur de marchand connect^ au rfeeau 
15 d'une demande d'autorisation de transaction, ou "ticket dc .paiement",. concernant 

un achat envisage entrc le marchand ct un client, el comportant des informations 
relatives au marchand, au client, a l'objet de l'achat et a son prix, 

- transmission du ticket dc paicment via le rcseau informatique a un 
poste serveur de paiement distinct des postes clients ct serveurs dc marchands, 

20 - verification automatique par le serveur de paiement si le paicment du 

prix est autorise pour le client conceme, la verification ctant cffcctuec, scion le 
montant du prix a payer, soit par interrogation d r un compte proprc au client, tcnu 
par le serveur dc paiement, ct destine au paiement des petits montants, soit par 
interrogation sur un r6scau bancairc independant du rescau informatique, pour les 

25 paiemcnts dc montants plus devfe, 

- si la verification est positive, elaboration par le serveur dc paicment 
d'une autorisation de transaction ou bon dc caissc comportant au moins unc partie 
des informations du ticket dc paiement, ct 

- transmission du bon dc caissc au serveur dc marchand via le rcscau 
30 informatique, afin rfautoriscr la realisation de Tachat . 

Ainsi, 1c proc£de scion Tinvcntion est remarquablc en ce qu'il 
tfimpliquc ni la citation dc monnaie clcctronique, ni la circulation dc monnaie 
eicctronique sur le r6scau informatique. 

La gestion des transactions est cffcctu6c par un serveur de paicment 
35 qui seul pcut acedder a un rcscau bancaire ou un reseau dc carte bancairc, et qui 
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gere dcs comptes clients non bancaires sur lesquels des transactions de faibles 
montants pcuvent etre effectuees. 

Le servcur de paiement gere egalement des comptcs marchands non 
bancaires utilises pour ies transactions de faibles montants. Ainsi, lorsqu'un bon de 
caisse est transmis apres verification par interrogation d'un compte client tenu par 
lc servcur de paiement, le montant de l'achat est d6bire du compte client et crcdite 
sur un compte marchand propre au marchand concern* et tenu par le servcur de 
paiement, ce qui n'entraine pas des couts de traitement Aleves. 

Chaque client dispose d'une identite qui lui est propre pour pouvoir 
utiliser le precede dc paicmcnt. II doit Egalement disposer d'un compte bancaire 
reel, de preference un compte utilisable au moyen du systeme traditionnel des 
cartes bancaires. La verification par le servcur de paiement peut comprendre une 
phase prealable de validation de I'identit6 du client a partir du contenu du ticket de 
paicmcnt. La validation de 1'idcntite est une operation prealable a I'acces eventuel 
au compte du client, si le montant de l'achat est faible, et/ou a I'acces au reseau 
bancaire si le montant est plus elev6. Le serveur de paiement comporte de 
preference des moyens, par exemple une base de donnees, permettant de 
meraoriser les relations entrc les identites des clients utilises pour les transactions 
sur le reseau informatique et des identity bancaires (numdros de comptcs 
bancaires ou numeros de cartes de credit) utilisees pour les transactions sur le 
reseau bancaire. On peut evitcr de la sortc la circulation d'identites bancaires sur le 
reseau informatique. 

Un mode de realisation de ^invention sera maintenant decrit a ritrc 
indicatif, mais non liroitatif, en reference aux dessins annexes sur lesquels : 

- Ia figure 1 est une vue g6neralc tres schematique d'un systeme de 
paiement 61ectronique conforme a 1'invention ; 

- la figure 2 est une representation sous forme d'un schema bloc d'un 
serveur dc paiement du systeme de la figure 1 ; 

- la figure 3 illustrc le d6roulement des operations relatives a un achat 
30 au moyen du systeme dc la figure 1 ;ct 

-les figures 4A a 4C sont des organigrammes monrrant tres 
schematiquement les operations effectuees par le servcur de paiement. 

Sur la figure 1 est represent^ de facon tres schematiquc un reseau de 
telecommunication informatique 10 sur lequel sont conncctes dcs postcs serveurs 
de marchands 20, des postcs clients 30 et au moins un poste serveur dc paiement 
40. 
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Le reseau informatiquc 10 est un reseau ouvert ou public, par cxcmple 

1c reseau denommc "Internet". 

Les serveurs de marchands 20 sont des unites telles que celles 
couramment utilisees pour des serveurs telematiques connectes sur "Internet", par 
5 exemple des unites organisecs autour de machines "Unix" rnultiprocesseurs. 

Les postes clients 30 sont essentiellement des micro-ordinateurs qui 
sont munis de moyens de connexion au reseau "Internet" 10, par exemple sous 
forme d'interface "Web". Les serveurs de marchands 20 et de postes clients 30 
utilisent par exemple des logiciels connus sous la denomination "World Wide 
10 Web" (WWW) utilisant le protocole HTTP. 

Le serveur de paiement 40, montre avec plus de details sur la figure 2, 
comprend des unites frontale et dorsale respectivement 41 et 42 connectees toutes 
les deux au rescau "Internet" 10. L'unite frontale 41 a une architecture scmblablc a 
celle d'un serveur classique connecte sur un reseau tel qu'"Intemct"". L'unit* 
15 dorsale 42xoroporte une umte de traitement 43 a un ou plusicurs processeurs, une 
base de donnees 44 comportant des informations relatives aux marchands et clients 
abonnes au systeme de paiement, un rcgistrc de transactions 45, une unite 46 
d'interface avec un reseau bancaire ou un reseau de carte bancaire 50, et un bus de 
communication 47 ou autre liaison similaire pennettant de relier entre cux les 
20 differents constituants de l'unite dorsale 42. Une liaison securisee 48 pcrmet une 
communication bidirectionnelle entre l'unit6 frontale 41 et l'uniti de traitement 43. 
La communication avec le rescau informatiquc 10 est controlee par l'unit* frontale 
41 tandis que la gestion de la base de donnees 44 ainsi que le controle de la 
communication avec le reseau bancaire 50 sont assures par l'unite dorsale 42. 
25 La base de donnees 44 contient des informations relatives aux clients 

et aux marchands abonnes au systeme de paiement. Pour cbaque client, la base de 
donnees 44 contient l'identit* systeme du client ("CId"), identiti recue lore de 
l'abonncment au systeme, un comptc de client ou porte monnaie electronique 
("PME") destin6 au paiement de faibles montants, une identit* bancaire telle que 
30 numero de compte bancaire reel ou numero de carte de credit ainsi 
qu'eventuellement une clef d'acces ou mot de passe propre au client. Pour chaque 
marchand, la base de donnees 44 contient I'identite systeme du marchand ("Mid"), 
identite recue lors de l'abonnement au systeme, un compte de marchand, ou tiroir- 
caisse elcctronique ("TCE") destin6 a rencaissement des faibles montants et une 
35 identite bancaire telle que numero de compte bancaire reel. 



WO 96/32701 



PCT/FR96/00500 



5 



La figure 3 illustre schematiquement les differentes Stapes d'unc 
transaction portant sur un achat d'un bien par un client abonne a un marchand 
abonne. D pcut s'agir d'un bien materiel dont la livraison au client sera effectuee 
reellement apres conclusion de la transaction ou d'un bien immateriel (tel que de 
5 Tinforraation) qui peut etre foumie au client par le reseau inforraatique des le 
paiement dlectronique effectue. 

m Consultation par le p)j fn t 

Par connexion sur le reseau "Internet" 10, un client peut consulter en 
ligne le catalogue ou la "virrine" d'un marchand quelconque par acces au serveur 
10 20 du marchand et par visualisation sur I'ecran du poste client 30 des biens ou 
services du marchand. Sur presentation dc l'identite CId du client, le serveur du 
marchand peut presenter au client des conditions financieres particulieres (par 
exemple une remise) applicables a la transaction eventuelle. 
(2\ Demande d'arhat 

15 chow du client 6tant anete sur un bien O, il est transmis au serveur 

du marchand sous forme d'un message contenant une identite Old du bien et 
l'identite CId du client. Lorsquc cela est necessaire, par exemple pour la livraison 
ultencure du bien choisi, des informations complcmentaircs (par exemple une 
adresse et un boraire de livraison pnSftre} Cela peut etre realise de facpn 

20 commode en utilisant un formulairc electronique envoye sur le reseau et destine a 
etre rempli par le client. 

Dans le cas ou 1'achat envisage represente un montant 6lev6 ou est 
soumis a des conditions Icgalcs, une authentification prealable du client peut etre 
souhaitee. Comme on le vena en d£tail plus loin l'autbcnhfication d'un client est 

25 effectuee par le serveur de paiement 40. Aussi, une demande d'authentification 
provenant d'un marchand est emise avantageusement sous la forme d'un ticket de 
paiement dc valeur nulle qui est transmis au serveur de paiement par le reseau 
infonnatique via le poste client et, en cas d'authentification positive, provoque le 
retour d'un bon de caissc du serveur de paiement au serveur marchand, toujours via 

30 le poste client. Les procedures d'&ablissement d'un ticket de paiement et de renvoi 
d'un bon de caisse sont decrites plus en d6tail ci-apres. 

La demande d'achat emise par le client peut porter sur un seul bien ou 
sur plusieurs biens a foumir de facon groupee : "achat panier". 
(3) Elaboration de la demande de pa^nt 

35 En nfponse a une demande d'achat, le serveur marchand llabore une 

demande de paiement qui peut comprendre les informations suivantes : 
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- Identite du marchand, ("Mid"); 

- Description du bicn commande, ou dc chacun des biens du panier, cn 
cas d'acbats groupes; 

- Type de transaction (simple ou panier); 
5 - Identite du client, ("Cld"), 

- Identity du bien ou de l'ensemble des biens du panier, ("Old"), 
-Prixderobjet,("Oid"); 

- TVA (si applicable); 

- Date et heurc dc remission du ticket de paiement (horodatage par le 

10 serveur marchand); 

- Duree de validitd du ticket de paiement; 

- Numcro de serie dans le registre des ventes du marchand (notammcnt 
dans le cas ou la transaction a comporte une etape prealable d'authentification). 

L'ensemble des informations ci-dessus est encodee dans une chaine 
15 d'octets qui constitue la chaine opaque d'un ticket de paiement (ou URL de 
commande de bien, URL etant les initiales de "Uniform Resource Locator" ou 
Localisateur de Ressource Unifonne utilise dans les logiciels WWW avec 
protocole HTTP), comme suit: 

URL http : < SP> < descriptif de la commando , 
20 oil SP est radresse "Internet" du serveur de paiement. Le ticket de paiement est 
adresse au poste client. 11 est compete par deux "ancres" logiques qui permettent 
au client soit de l'annuler, soit dc le confirmcr. 

(d) Ftjvni He Pordre de paiement 

L'ordxt de paiement est transmis au serveur de paiement simplement 
25 par validation par le client de l'URL dc demande de paiement. On comprendra 
bien que le ticket de paiement ne fait alors que transitcr par le poste client. 
(*} f,TCfW irm du hon de 

Sur reception d'un ordrc de paiement, le serveur de paiement 40 le 
decode et precede a I'authentification du client et recherche si le paiement peut etre 
30 autorise avant dc retoumer un bon de caisse ou un refus de paiement. 

Us operations d'authentification de client et d'autorisation de paiement 
scront decrites plus loin en detail en reference a la figure 4. 

Lorsque les verifications effectuees ne permettent pas d'autoriser le 
paiement, une notification de refus motivee est adrcsscc au client par le serveur de 
35 paiement (indiquant, par cxemple, compte insuffisamment approvisionnd, 
depassement d'un scuil autorise" pour le client, ...) 
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Lorsque les verifications effectuces pcnmcttent d'autoriser le paiement, 
lcs informations contcnucs dans lc ticket de paiement sont completees avec un 
numero de seric dans ie rcgistre des transactions 45, une estampille horaire, une 
duree de validity (typiquement quelqucs dizaines de secondes) ct Ie sceau du 
5 serveur de paiement constituant une information de certification. L'ensemble de 
ces informations, 6ventuellement aprfes signature num6rique par I'utilisation dc la 
partie de clef privee d'un systeme de chiffrement a clef priveetelef publique du 
serveur de paiement (ce qui garantit la validite et l'integrite de l'autorisation de 
paiement), est encode dans une chaine d'octets qui constitue la chaine opaque d'un 
10 bon de caisse ou URL de li vraison : 

URL http : <M> <descriptif du bon de caisse> , 
ou <M> est l'adresse "Internet " du marchand. 

(6) Demande de livnrisftn 

Le bon de caisse est transmis au serveur du marchand via le poste 
15 client. Ceci peut etre effectue automatiquement par le logiciel implante au poste 
client en utilisant la possibility de re-routage des URL bien connue de lhomme du 
metier. Avant d'autoriser la livraison du bien, le serveur du marchand opfcre un 
decodage et une verification du bon de caisse re$u. Cctte verification consistc a 
utiliser la clef privee eventuelle du serveur de paiement, a verifier que la durce dc 
20 validity n'est pas ecoulee, et a rapprocher le contenu du bon de caisse avec celui de 
la demande de paiement. 

(7) Livraison fa bien 

Lorsque le bon de caisse est valide par le serveur du marchand, celui- 
ci peut effectuer la livraison directe sur le poste client, dans le cas de bien 
25 ^information, ou adresse au poste client un document pennettant le rctrait du bien 
et prfcisant notamment le lieu de livraison et le nom du rccipiendaire. 

On notera que, dans le cas d'un achat groups (panier), il y a creation 
par le serveur du marchand d'un objet avec affectation d*une identite unique. Get 
objet est la liste des URL de cbacun des biens du panier. Cest cet objet qui est 
30 indique dans 1TJRL de commande de bien et qui permettra d'enregistrer le detail 
des biens achet£s dans le registre de transaction du serveur dc paiement. 

Les figures 4A a 4C montrent les op6rations effectu£es par le serveur 
de paiement 40 en reponse a la reception d'un ordre de paiement. 

Dans l'unitS frontale 41 (figure 4A), l'ordre de paiement est decod6 
35 (etape 61) et sa validite est exarain6e (test 62) notamment du point de vue de la 
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duree de validite. Si lc resultat dc l'examen est ncgatif, une notification de refus est 
envoyee au poste client (Itape 63). 

Si le r&ultat de l'cxamen est positif, il est precede ensuite a une 
authentification du client (dtape 64), le detail de cette operation etant decrit plus 

5 loin en reference a la figure 4C. Si I'authentification est negative (test 65), une 
notification dc refus est envoyee au client (etape 63). Si elle est positive, rordre de 
paicmcnt (6ventuelleraent liroite a l'identit6 CId du client, a l'identite Mid du 
roarchand, et au prix) est transmis via la liaison 68 a I'unite dorsale 42 du serveur 
de paiernent represente sur la figure 2 (etape 66). La liaison 48 est une liaison 

10 securisee interdisant I'acces a I'unite dorsale a toute personne se connectant sur le 
reseau 10. 

L'unite frontale 41 attend alors que I'unite dorsale decide d'autoriscr ou 
non le paiernent (etape 67). Si le paiernent n'est pas autorise, (test 68), une 
notification de refus est envoyee au poste client (6tape 63). Si le paiernent est 
15 autorise, un bon de caisse est elaborc (etape 69), utilisant les informations 
enregistrees a l'6tape 62. Le bon de caisse est enrcgistrc dans une mdmoire dc 
I'unite frontale 41 (etape 70) et est adresse au serveur du roarchand via Ic poste 
client (etape 71). 

Au niveau de l'unit6 dorsale 42 (figure 4B) du serveur de paiernent, a la 
20 reception d'un ordre de paiernent authentifie, il est examine si celui-ci doit etre 
autorise a partir du compte client PME via le reseau bancairc 50. A cet effet, le 
prix est compare a un seuil minimum (test 72). Ce seuil est par exemple de 
quelques dizaines de francs. 

Si lc seuil est depassi, une demande pour effectuer l'operation de 
25 paiernent est lancee sur le reseau bancaire (6tape 73) en utilisant l'identite bancairc 
corrcspondant a l'identite CId du client, tcUe qu'clle ressort de la consultation de la 
base de donnees 44. A la reception de la reponse positive ou negative (6tape 74), 
celle-ci est transmise a l'uniti frontale 41 (itape 75). 

Si le seuil n'est pas depasse, le paiernent peut etre effectu6 a partir du 

30 compte PME du client. 

A cet effet, il est examine si le compte est suffisamment approvisionn6 
(test 76). Dans la negative, un refus d'autorisation de paiernent, e'est-a-dire une 
reponse negative, est renvoyee a l'unit6 frontale (etape 75). Dans 1'affixmative, le 
compte PME du client est debit* du prix et le compte TCE de marchand 

35 corrcspondant a l'idcntit6 Mid est cx6dite du meroe montant (6tape 77), la 
transaction est inscrite dans le registre des transactions 45 (etape 78) et 
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I'autorisation de paiement, c'est-a-dire une reponse positive est transmise a lunite 
fiontale 41 avec I'indication du numero de scrie de 1'inscription dans le registre de 
transactions (etape 75). 

La procedure d'authentiOcation dans le serveur de paiement (figure 
4Q, a l'6tape 64 de la figure 4A, comprend l'envoi au poste client, de preference 
dans une forme securiscc (chiffree), d'une demande de cl6 d'acces, ou mot de passe 
(etape 641). A la reception securiscc dc la c\6 d'acces (6tape 642), une comparaison 
est effectuee avec une information correspondantc contenuc dans la base de 
donnees 44 (test 643). 

Si la comparaison est negative, et qu'un nombre maximum de 
tcntatives infructueuses n'a pas ete atteint (test 644), on retoume a r6tape 641. Si ce 
nombre maximum est atteint, I'absence d'authentification est constatee, une alerte 
est produite (etape 645) ct une reponse negative est envoyee au poste client (etape 
646). L'alerte peut consistcr en une annulation du compte PME ou en une 
15 surveillance de celui-ci afin de detecter de nouvclles tcntatives d'utilisation. Si le 
test a I'ftape 643 est positif, I'authentification est enrcgistrce (6tape 647) et une 
reponse positive est elaboree (etape 648). 

Dcs techniques de chiffrement permettant la transmission securiscc 
^informations numcriqucs sur rcseau informatique, notamment pour la demande 
20 d'envoi de de d'acces et l'envoi de cellc-ci, sont bien connues. 

La procedure d'authentification decrit ici pennet d'effectuer une 
authentification prealable d un client dans le cas ou celle-ci est nccessaire avant 
reteblissement d'une demande de paiement par le serveur du marchand. Pour cctte 
authentification, it suffit alors en effet dc creer un ticket de paiement dans lequel le 
25 prix indique est mil, comme indiqud plus haut. 

L'enregistrement dcs bons de caisse dans l'unit6 fiontale pennet aux 
clients et aux marchands de proedder a des contr61es et d'en obtenir 6ventuellement 
des copies. L'enregisrrement des transactions dans l'unit6 dorsale permet d'en 
conserver une trace en cas, par exemple, dc contestation entrc un client et un 
30 marchand. 

Les comptes clients PME geres par le serveur de paiement ont cn 
principe un montant de solde plafonne et, selon le mode de realisation preiere de 
l'invention, ils ne sont pas rcmuneres (le systeme de paiement se trouvant en 
dehors du monde bancaire). Un rcapprovisionnement dc son compte PME par un 
client peut etre effectue a partir de son compte bancaire, par ordre donn6 a son 
etablissement bancaire. 
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Les comptcs maichands TCE g£res par le seivcur dc paiement sont 
associes a des coniptes bancaires reels des maichands dans lesquels ils sont vides 
par exemple quotidiennement, 

Bien que l'on ait decrit ci-avant un mode de mise en oeuvrc d'un 
5 procedc selon I'invention dans un environnement "Internet" et avec des logiciels 
WWW utilisant le protocole HTTP, I'homme de Tart comprendra aiseraent que le 
procede peut etre mis en oeuvre avec un reseau infonnatique autre qu ,w Intcniet" ou 
encore avec des logiciels serveur marchand et client n'utilisant pas le protocole 
HTTP de WWW. En outre des procedes d'authentification securisfe mettant en jeu 
10 des dispositifs matericls tcls que lecteur de carte a puce ou moyen de 
reconnaissance d'cmpreinte vocale pourront etre prevus a la place de clefs d'accfes. 
Ces dernieres et d'autre modifications qui viendront a I'esprit du I'homme du metier 
sont comprises dans la philosophic et la portee de la presente invention. 
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REVINDICATIONS 

1. Proc&ie de paicment 6lectronique pour dcs transactions liees a l'achat 

de bicns offerts par des marchands a dcs clients via un reseau infonnatiquc ouvcrt 
sur IcqucI sont conncctcs des posies serveurs de marchands et des postes clients, 
caracterise par les etapes de : 

- Elaboration par un poste serveur de marchand connects au reseau 
d'une demande d'autorisation de transaction, ou ticket de paiement, conccmant un 
achat envisage entre le marchand et un client, et comportant des informations 
relatives au marchand, au client, a l'objet de l'achat et a son prix, 

- transmission du ticket de paiement via le reseau informatique a un 
serveur de paiement distinct des postes clients et serveurs de marchands, 

- verification automat i que par le serveur de paiement si le paiement du 
prix est autorise pour 1c client concerne, la verification etant effectuee, selon le 
montant du prix a payer, soit par interrogation d'un compte client propre au client, 
tenu par le serveur de paiement, ct destine au paiement despctits montants, soit par 
interrogation sur un reseau bancairc independant du reseau informatique, pour les 
paiements de montants plus Aleves, 

- si la verification est positive, Elaboration par le serveur de paiement 
d'une autorisation de transaction ou bon de caisse comportant au moins une partie 

20 des informations du ticket dc paiement, et 

- transmission du bon de caisse au serveur de marchand via le reseau 
informatique, afin d'autoriser la realisation de l'achat. 

2. Precede selon ia revendication 1, caracterise en ce que lorsqu'un bon 
de caisse est transmis apres verification par interrogation d'un compte client tenu 
par le serveur de paiement, le montant de l'achat est debit* du compte client et 
cr6dite sur un compte marchand propre au marchand concerne et tenu par le 
serveur de paiement. 

3. Precede selon Tunc quelconque des revendications 1 ct 2, caracterise 
cn ce que la verification par le serveur de paiement comprend une phase prcalable 

30 d'authentification du client. 

4. Proc&ll scion la revendication 3, caracterise' en ce que 
I'authentification est rcaliscc par reconnaissance d'une clef d'acces transmise par le 
reseau informatique du poste client au serveur de paiement. 

5. Precede selon l'une quelconque dcs revendications 1 a 4, caracterise en 
ce qu'il comprend l'elaboration par ie serveur de paiement d'un bon de caisse 
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comport ant au moins une paitie des informations du ticket de paiement et unc 
information dc certification. 

6. Precede selon Tune quelconque des revendications 1 a 5, caracterise en 
ce qu ! il comprend la memorisation par le serveur de paiement des transactions 

5 autorisees, par stockage d ! au moins une partie du contenu des bons de caisse. 

7. Procede selon Tune quelconque des revendications 1 a 6, caracterise en 
ce que le ticket de paiement est transmis du serveur du marchand au serveur de 
paiement par Tintenn6diairc du poste client. 

8. Procede selon I'une quelconque des revendications 1 a 7, caracterise en 
10 ce que le bon dc caisse est transmis du serveur de paiement au serveur du 

marchand par rintermediaire du poste client. 

9. Systeme de paiement electronique pour effectuer des transactions liees 
a l'achat de biens offerts par des marchands a des clients via un reseau infonnatique 
ouvert, le systeme comport ant des postes clients et des postes servcurs dc 

15 marchands pouvant etre connect cs sur le reseau ouvert, 

systeme caracterise en ce qu'il comporte en outre au moins un poste serveur de 
paiement distinct des postes clients et serveurs de marchands et comprenant : 

- une unit6 frontale munie de moyens de connexion au reseau ouvert, 

- une unite dorsale munie de moyens de connexion a un reseau 
20 bancaire independant du reseau ouvert, 

- des moyens de communication cntre les unites frontale et dorsale, 

- des moyens de memorisation de comptes de clients, de comptes de 
fournisseurs, et 

- des moyens de traitement pour, en reponse a la reception par l'unite 
25 frontale dune demande d'autorisation de transaction ou ticket de paiement, 

concemant un achat envisage entre un marchand et un client, verifier si le paiement 
du prix est autorise pour le client conceme par interrogation du compte du client 
ou du reseau bancaire et, si la verification est positive, eiaborer une autorisation de 
transaction, ou bon de caisse afin dc la transmettre sur le reseau ouvert via Tunite 
30 frontale. 

10. Systeme de paiement selon la revendication 9, caracterise en ce que le 

serveur de paiement comprend des moyens de memorisation des transactions 
autorisees. 
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